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An In-Band Data Communication Network For the MPLS Transport Profile 
Abstract 


The Generic Associated Channel (G-ACh) has been defined as a 
generalization of the pseudowire (PW) associated control channel to 
enable the realization of a control/communication channel that is 
associated with Multiprotocol Label Switching (MPLS) Label Switched 
Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between 
adjacent MPLS-capable devices. 


The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS 
architecture that identifies elements of the MPLS toolkit that may be 
combined to build a carrier-grade packet transport network based on 
MPLS packet switching technology. 


This document describes how the G-ACh may be used to provide the 
infrastructure that forms part of the Management Communication 
Network (MCN) and a Signaling Communication Network (SCN). 
Collectively, the MCN and SCN may be referred to as the Data 
Communication Network (DCN). This document explains how MCN and SCN 
messages are encapsulated, carried on the G-ACh, and demultiplexed 
for delivery to the management or signaling/routing control plane 
components on an MPLS-TP node. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5718. 
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Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


1. Introduction 


The associated channel header (ACH) is specified in [RFC4385]. It is 
a packet header format for use on pseudowires (PWs) in order to 
identify packets used for Operations, Administration, and Maintenance 
(OAM) and similar functions. 


The use of the ACH is generalized in [RFC5586] and can be applied on 
any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP). 
This is referred to as the Generic Associated Channel (G-ACh) and is 
intended to create a control/management communication channel 
associated with the LSP that can be used to carry packets used for 
OAM and similar functions (e.g., control/management plane messages). 


The purpose of a packet carried on the G-ACh is indicated by the 
value carried by the Channel Type field of the ACH and a registry of 
values is maintained by IANA ([RFC4446] and [RFC4385]). The ACH is 
referred to in this document as the G-ACh header. 


The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in 
[RFC5654]. MPLS-TP is the application of MPLS to construct a packet 
transport network. It constitutes a profile of MPLS that enables 
operational models typical in transport networks, which includes 
additional OAM, survivability, and other maintenance functions not 
previously supported by MPLS. 


Label Switching Routers (LSRs) in MPLS networks may be operated using 
management protocols or control plane protocols. Messaging in these 
protocols is normally achieved using IP packets exchanged over IP- 
capable interfaces. However, some nodes in MPLS-TP networks may be 
constructed without support for direct IP encapsulation on their 
line-side interfaces and without access to an out-of-fiber data 
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communication network. In order that such nodes can communicate 
using management plane or control plane protocols, channels must be 
provided, and the only available mechanism is to use an MPLS label. 


The G-ACh provides a suitable mechanism for this purpose, and this 
document defines processes and procedures to allow the G-ACh to be 
used to build a Management Communication Network (MCN) and a 
Signaling Communication Network (SCN), together known as the Data 
Communication Network (DCN) [G.7712]. 


It should be noted that the use of the G-ACh to provide connectivity 
for the DCN is intended for use only where the MPLS-TP network is not 
capable of encapsulating or delivering native DCN messages. 


1.1. Requirements 


The requirements presented in this section are based on those 
communicated to the IETF by the ITU-T. 


1. A packet-encapsulation mechanism must be provided to support the 
transport of MCN and SCN packets over the G-ACh. 


2. The G-ACh carrying the MCN and SCN packets shall support the 
following application scenarios: 


a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when 
the server layer does not provide a Management Communication 
Channel (MCC) or a Signalling Communication Channel (SCC)). 


b. The G-ACh is carried by an MPLS-TP tunnel that traverses 
another operator’s domain (the carrier’s carrier scenario). 


3. The G-ACh shall provide two independent channels: an MCC to build 
the MCN and an SCC to build the SCN. The G-ACh packet header 
shall indicate whether the packet is an MCC or an SCC packet in 
order to forward it to the management or control plane application 
for processing. This facilitates easy demultiplexing of control 
and management traffic from the DCN, and enables separate or 
overlapping address spaces and duplicate protocol instances in the 
management and control planes. 


4. The channel-separation mechanism shall not preclude the use of 
separate rate limiters and traffic-shaping functions for each 
channel (MCC and SCC), ensuring that the flows do not exceed their 
assigned traffic profiles. The rate limiters and traffic shapers 
are outside the scope of the MCC and SCC definitions. 
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5. The G-ACh that carries the MCC and SCC shall be capable of 
carrying different OSI layer 3 (network layer) PDUs. These shall 
include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC 
packet shall indicate which layer 3 PDU is contained in the 
payload field of the packet such that the packet can be delivered 
to the related layer 3 process within the management and control 
plane application, respectively, for further processing. 


6. The G-ACh is not required to provide specific security mechanisms. 
However, the management or control plane protocols that operate 
over the MCC or SCC are required to provide adequate security 
mechanisms in order to not be susceptible to security attacks. 


1.2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
in this document are to be interpreted as described in RFC-2119 
[RFC2119]. 


2. Procedures 


Figure 1 depicts the format of an MCC/SCC packet that is sent on 
the G-ACh. The Channel Type field indicates the function of the 
ACH message and so, to send an MCC/SCC packet on the G-ACh, the 
MCC/SCC message is prepended with an ACH with the Channel Type set 
to indicate that the message is an MCC or SCC message. The ACH 
MUST NOT include the ACH TLV Header [RFC5586], meaning that no ACH 
TLVs can be included in the message. A two-byte Protocol 
Identifier (PID) field indicates the protocol type of the payload 
DCN message. 


0 1 2 3 
0123456789012 3456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|o 0 0 1|Version| Reserved | Channel Type 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| PID | | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| MCC/SCC Message | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 1: G-ACh MCC/SCC Packet 


o The Channel Type field determines whether the message is an MCC or 
an SCC message. See Section 5 for the codepoint assignments. 
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o The presence of the PID field is deduced from the Channel Type 


value indicating MCC or SCC. The field contains an identifier of 
the payload protocol using the PPP protocol identifiers ([RFC1661], 
[RFC3818]). 


When the G-ACh sender receives an MCC message that is to be sent over 
the MCC, the sender creates the G-ACh header, sets the Channel Type 
field to MCC, fills in the PID to indicate the MCC layer 3 PDU type, 
and prepends the MCC message with the G-ACh header. The same 
procedure is applied when a control plane message is to be sent over 
the SCC. In this case, the sender sets the Channel Type field to 
SCE, 


If the G-ACh is associated with an MPLS section, the Generic 
Associated Channel Label (GAL) is added to the message as defined in 
[RFC5586]. The Time to Live (TTL) field MUST be set to 1, and the 
S-bit of the GAL MUST be set to 1. 


If the G-ACh is associated with an LSP, the GAL is added to the 
packet and the LSP label is pushed on top of the GAL as defined in 
[RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit 
of the GAL MUST be set to 1. 


Note that packet processing for DCN packets in the G-ACh is, in 
common with all G-ACh MPLS packets, subject to the normal processing 
of the Traffic Class (TC) field of the MPLS header. This could be 
used to enable prioritization of different DCN packets. 


The DCN channel MUST NOT be used to transport user traffic and SHALL 
only be used to carry management or control plane messages. 
Procedures that ensure this (such as deep packet inspection) are 
outside the scope of this specification. 


When a receiver has received a packet on the G-ACh with the ACH 
Channel Type set to MCC or SCC, it SHALL look at the PID field. If 
the PID value is known by the receiver, it delivers the MCC/SCC 
message to the appropriate processing entity. If the PID value is 
unknown, the receiver SHALL silently discard the received packet, MAY 
increment a counter that records discarded or errored messages, and 
MAY log an event. 


It must be noted that according to [RFC5586], a receiver MUST NOT 
forward a GAL packet based on the GAL label as is normally the case 
for MPLS packets. If the GAL appears at the bottom of the label 
stack, it MUST be processed as described in the previous paragraph. 
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Note that there is no requirement for MPLS-TP devices to support IP 
or OSI forwarding in the fast (forwarding) path. Thus, if a message 
is received on the MCC or SCC and is not targeted to an address of 
the receiving MPLS-TP node, the packet might not be forwarded in the 
fast path. A node MAY apply layer 3 forwarding procedures in the 
slow or fast path and MAY discard or reject the message using the 
layer 3 protocol if it is unable to forward it. Thus, protocols 
making use of the DCN should make no assumptions about the forwarding 
capabilities unless they are determined a priori or through the use 
of a routing protocol. Furthermore, it is important that user data 
(i.e., data traffic) is not routed through the DCN, as this would 
potentially cause the traffic to be lost or delayed and might 
significantly congest the DCN. 


2.1. Pseudowire Setup 


Provider Edge nodes (PEs) may wish to set up PWs using a signaling 
protocol that uses remote adjacencies (such as LDP [RFC5036]). In 
the absence of an IP-based control plane network, these PEs MUST 
first set up an LSP tunnel across the MPLS-TP network. This tunnel 
can be used both to carry the PW once it has been set up and to 
provide a G-ACh-based DCN for control plane communications between 
the PEs. 


3. Applicability 


The DCN is intended to provide connectivity between management 
stations and network nodes, and between pairs of network nodes, for 
the purpose of exchanging management plane and control plane 
messages. 


Appendix A of [NM-REQ] describes how Control Channels (CCh) that are 
the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in- 
fiber and out-of-band, or in-band with respect to the user data 
carried by the MPLS-TP network. That appendix also explains how the 
DCN can be constructed from a mix of different types of links and how 
routing and forwarding can be used within the DCN to facilitate 
multi-hop delivery of management and control plane messages. 


The G-ACh used as described in this document allows the creation of a 
"data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) and 
an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the former 
case, the G-ACh is associated with an MPLS-TP section. In the latter 
case, the G-ACh is associated with an MPLS-TP LSP or PW and may span 
one or more hops in the MPLS-TP network. 
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There is no need to create a CCh for every LSP between a pair of 
MPLS-TP nodes. Indeed, where the nodes are physically adjacent, the 
G-ACh associated with the MPLS-TP section would normally be used. 
Where nodes are virtually adjacent (that is, connected by LSP 
tunnels), one or two of the LSPs might be selected to provide the CCh 
and a back-up CCh. 


4. Security Considerations 


The G-ACh provides a virtual link between MPLS-TP nodes and might be 
used to induce many forms of security attack. The MPLS data plane 
does not include any security mechanisms of its own; therefore, it is 
important that protocols using the DCN apply their own security. 
Protocols that operate over the MCN or SCN are REQUIRED to include 
adequate security mechanisms, and implementations MUST allow 
operators to configure the use of those mechanisms. 


5. IANA Considerations 


Channel Types for the Generic Associated Channel are allocated from 
the IANA PW Associated Channel Type registry defined in [RFC4446] and 
updated by [RFC5586]. 


IANA has allocated two further Channel Types as follows: 
0x0001 Management Communication Channel (MCC) 
0x0002 Signaling Communication Channel (SCC) 
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